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(57) A unified policy management system for an or- 
ganization including a central policy server and remotely 
situated policy enforcers. A central database and policy 
enforcer databases storing policy settings are config- 
ured as LDAP databases adhering to a hierarchical ob- 
ject oriented structure. Such structure allows the policy 
settings to be defined in an intuitive and extensible fash- 
ion. Changes in the policy settings made at the central 
policy server are automatically transferred to the policy 
enforcers for updating their respective databases. Each 
policy enforcer collects and transmits health and status 
information in a predefined log format and transmits it 
to the policy server for efficient monitoring by the policy 
server. For further efficiencies, the policy enforcement 



functionalities of the policy enforcers are effectively par- 
titioned so as to be readily implemented in hardware. 
The system also provides for dynamically routed VPNs 
where VPN membership lists are automatically created 
and shared with the member policy enforcers. Updates 
to such membership lists are also automatically trans- 
ferred to remote VPN clients. The system further pro- 
vides for fine grain access control of the traffic in the 
VPN by allowing definition of firewall rules within the 
VPN. In addition, policy server and policy enforcers may 
be configured for high availability by maintaining a back- 
up unit in addition to a primary unit. The backup unit be- 
come active upon failure of the primary unit. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to computer net- 
works, and more particularly, to devices and methods 
for providing efficient, integrated and scalable policy 
management services for remote private networks 
across the Internet. 

BACKGROUND OF THE INVENTION 

[0002] The growth and proliferation of computers and 
computer networks allow businesses to efficiently com- 
municate with their own components as well as with their 
business partners, customers, and suppliers. However, 
the flexibility and efficiencies provided by such comput- 
ers and computer networks come with increasing risks, 
including security breaches from outside the corpora- 
tion, accidental release of vital information from within 
it, and inappropriate use of the LAN, WAN, Internet, or 
extranet. 

[0003] In managing the growth of computer networks 
as well as addressing the various security issues, net- 
work managers often turn to network policy manage- 
ment services such as firewall protection, Network Ad- 
dress Translation, spam email filtering, DNS caching, 
Web caching, virtual private network (VPN) organization 
and security, and URL blocking for keeping network us- 
ers from accessing certain Web sites through use of the 
organization's ISP. Each policy management service, 
however, generally requires a separate device that 
needs to be configured, managed, and monitored. Fur- 
thermore, as an organization grows and spreads across 
multiple locations, the devices maintained also multiply, 
multiplying the associated expenditures and efforts to 
configure, manage, and monitor the devices. 
[0004] The solution to this problem is not as simple as 
just integrating multiple network policy management 
functions into a single device at each location and al- 
lowing each location to share its policy information with 
other locations. In fact, there are many obstacles and 
challenges in adopting such an approach. For example, 
a scheme for specifying and distributing policy manage- 
ment information effectively across remote private net- 
works of an entire organization generally requires a well 
designed object model. The synchronizing of multiple 
databases in the organization with updates to the policy 
management information may also be a complex prob- 
lem. Moreover, managing the policy information effi- 
ciently for remote devices across an organization may 
present a challenge. Furthermore, collecting logs and 
statistics information from the remote private networks 
in a large distributed policy management system for ef- 
ficient analysis and report generation is often a difficult 
task. Conventionally, only raw packet information is 
logged and saved, generally requiring time-consuming 
and custom-generated programs to be run on the raw 



data off-line to produce meaningful reports and statis- 
tics. 

[0005] There are other challenges in providing a uni- 
fied policy management system. For increased benefits, 

5 such unified policy management functions should be im- 
plemented as much as possible in hardware. However, 
implementing policy management on a chip typically re- 
quires an efficient design partitioning. Furthermore, the 
unified policy management system should allow for ef- 

10 ficient configuration, management, and updating of vir- 
tual private networks extending over different remote 
sites. 

[0006] Accordingly, there remains a need in the art for 
a network management solution that overcomes these 
15 and other obstacles of the prior art. 

SUMMARY OF THE INVENTION 

[0007] The present invention is directed to a unified 
policy management system where various policies, 
namely, the set of rules and instructions that determine 
the network=s operation, may be established and en- 
forced from a single site. According to one embodiment 
of the invention, the system includes a first edge device 
associated with a first network having a first set of re- 
sources that is configured to manage the policies for the 
first network according to the policy settings stored in a 
first database. The system also includes a second edge 
device associated with a second network having a sec- 
ond set of resources that is configured to manage the 
policies for the second network according to the policy 
settings stored in a second database. The first and sec- 
ond edge devices act as policy enforcers for their re- 
spective networks. The policies being enforced may in- 
clude firewall policies, VPN policies, and the like. 
[0008] The system further includes a central policy 
server in communication with the first and second edge 
devices. The policy server is configured to define the 
first and second policy settings and manage the first and 
second edge devices from a single location. Thus, a net- 
work administrator need not multiply his or her efforts 
and associated expenditures in configuring and manag- 
ing the policy enforcers individually. 
[0009] In alternative embodiments, the unified policy 
management system includes one or more of the follow- 
ing features: 

[001 0] The central policy server may include a central 
database for storing configuration information of the pol- 
icy enforcers. 

[001 1] The central database as well as the databases 
associated with the policy enforcers are Lightweight Di- 
rectory Access Protocol (LDAP) databases organized 
according to a hierarchical object oriented structure. 
This structure includes resource objects and policy ob- 
jects for defining the policy settings for the policy enforc- 
ers. Such a structure helps simplify policy management 
by allowing the various elements of the policy manage- 
ment system to be defined and organized in an intuitive 
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and extensible fashion. 

[001 2] According to one embodiment of the invention, 
the resource objects include devices, users, hosts, serv- 
ices, and time. Devices are the policy enforcers at the 
edge of a particular private local network. Each device 
is associated with users and a host. A host is a network 
(e.g. a LAN subnet) in an organization. Services reflect 
the various services (e.g. HTTP, TELNET, FTP) provid- 
ed by the policy server. Time is another dimension in 
controlling access to the network resources. 
[0013] The central database stores the configuration 
information, including policy settings, for all the policy 
enforcers. When a change is made to the configuration 
information, the policy server creates a log of such 
changes and stores it in the central database for later 
transferring to the policy enforcers. When the policy en- 
forcers receive the log of changes, they update their re- 
spective databases accordingly and indicate to the pol- 
icy server whether the updates have been successful. 
If they have been successful, the log of changes corre- 
sponding to these policy enforcers are deleted from the 
central database. 

[0014] The central policy server may further include a 
set of user application modules for allowing a user, such 
as the network administrator, to define the policy set- 
tings for the policy enforcers and further manage the pol- 
icy enforcers from the single location. Preferably, the 
policy settings are associated with a plurality of resource 
objects including devices, users, hosts, services, and 
time. 

[001 5] In one aspect of the invention, the set of appli- 
cation modules includes a centralized management 
sub-module for allowing installation and registration of 
the policy enforcers with the central policy server. 
[0016] In another aspect of the invention, the set of 
application modules includes a policy management sub- 
module for managing and viewing the resource objects 
from the single location. 

[001 7] In yet a further aspect of the invention, the pol- 
icy server includes a set of user application modules for 
allowing a user to monitor the health and status of the 
policy enforcers. Each policy enforcer collects and 
transmits the health and status information to the policy 
server in a predefined common log format. The policy 
server may then create various reports based on this 
information. It should be appreciated, therefore, that the 
present invention allows on-the-fly monitoring of the re- 
sources in the organization, yielding further advantages 
of the invention over the prior art, which generally col- 
lected only raw data and required the tedious generation 
of reports. 

[0018] The functionalities of the policy enforcers in en- 
forcing the policies for their respective networks may al- 
so be partitioned for effective hardware implementation. 
According to one embodiment of the invention, each 
edge device preferably includes a plurality of modules 
including a classification engine, a policy engine, and a 
packet forwarding engine. The classification engine de- 



termines a protocol associated with an incoming packet. 
The policy engine makes a forwarding decision for the 
packet based on policy settings associated with the 
packet. The packet forwarding module then forwards 

5 the packet based on the policy settings. 

[0019] In alternative embodiments, the module may 
further include a security engine for authenticating a us- 
er transmitting the packet and/or a statistics module for 
collecting statistics of packets flowing through the policy 

10 enforcer. 

[0020] Each of the networks in the system may also 
constitute private networks and each policy enforcer as- 
sociated with the private network is configured to create 
a table with information of member networks reachable 
15 through the policy enforcer. The table is then shared with 
the other member policy enforcers in the VPN. This al- 
lows the creation of VPNs whose member lists are dy- 
namically compiled. 

[0021] In one particular aspect of the invention, the 

20 communication between the first and second private 
networks is managed according to a security policy as- 
sociated with the member networks. The security policy 
is preferably defined for a security policy group, referred 
to as a VPN cloud, providing a hierarchical organization 

25 of the group. The VPN cloud includes member networks 
(hosts), users allowed to access the member networks, 
and a rule controlling access to the member networks. 
The hierarchical organization provided by the VPN 
clouds thus allows the network administrator to create 

30 fully meshed VPNs where every site within a VPN cloud 
has full connectivity with every other site. The network 
administrator need no longer manually configure each 
possible connection in the VPN, but only need to create 
a VPN cloud and specify the sites, users, and rules to 

35 be associated with the VPN. Each connection is then 
configured based on the configuration specified for the 
VPN cloud. The hierarchical organization thus facilitates 
the setup of a VPN with a large number of sites. 
[0022] In another aspect of the invention, the rule in 

^0 the VPN is a firewall rule providing access control of the 
traffic among the member networks. Such firewall rules 
allow the administrator to have fine grained access con- 
trol over the traffic that flows through the VPN, all within 
the realm of the encrypted access provided by such 

45 VPN. 

[0023] In a further aspect of the invention, a remote 
user accesses the member networks from a remote lo- 
cation using a remote user terminal. The terminal is con- 
figured with software for downloading the table with the 
so dynamic membership information from the edge device 
to which it is connected. Updates to the membership in- 
formation are further automatically transmitted to the re- 
mote user terminal without requiring reconfiguration of 
the terminal. 

55 [0024] The policy server and policy enforcers, as well 
as other network devices may also be configured for 
high availability by maintaining a second class unit 
(backup unit) in addition to a first class unit (primary unit) 
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for preventing a single point of failure. In one aspect of 
the invention, the backup unit is initially in an inactive 
state and later transitions to the active state upon de- 
tection of a failure is the primary unit. 
[0025] In another aspect of the invention, each high- 5 
availability device discovers its status as a primary unit, 
a backup unit, or a stand-alone unit (third class unit) dur- 
ing initialization. 

[0026] In a further aspect of the invention, the config- 
uration information stored in the databases of the pri- 10 
mary and backup units are synchronized by transition- 
ing the first class unit to an active state, receiving and 
storing the first database configuration changes on the 
first class unit, transferring the configuration changes to 
the second class unit, and storing the configuration 15 
changes on the second class unit. When the primary unit 
transitions to an inactive state, the backup unit stores 
the second database configuration changes on the sec- 
ond class unit and transfers those changes to the pri- 
mary unit after it re-transitions to the active state. 20 
[0027] In still another aspect of the invention, updates 
to the primary and backup units, such as software up- 
dates, are also synchronized transmitting the update in- 
formation to the primary unit, updating the primary unit, 
transmitting the update from the primary unit to the back- 25 
up unit, and updating the backup unit. Thus, the network 
administrator need not duplicate his or her efforts to up- 
date the backup units. 

BRIEF DESCRIPTION OF THE DRAWINGS 30 

[0028] These and other features, aspects and advan- 
tages of the present invention will be more fully under- 
stood when considered with respect to the following de- 
tailed description, appended claims and accompanying 
drawings wherein: 

FIG. 1 is a schematic block diagram of an exempla- 
ry unified policy management system; 

FIG. 2 illustrates the hierarchical object-oriented 
structure of policies stored for an organization in ac- 
cordance with the principles of the invention; 

FIG. 3 is a schematic block diagram of a policy serv- 45 
er in the policy management system of FIG. 1; 

FIG. 4 is a schematic diagram of a central manage- 
ment sub-module in the policy server of FIG. 3; 

50 

FIG. 5 is an exemplary flow diagram of a device reg- 
istration process carried out by the central manage- 
ment sub-module of FIG. 4; 

FIG. 6 is a screen illustration of an exemplary graph- 55 
ical user interface for registering a device; 

FIG. 7 is a screen illustration of an exemplary global 



monitor user interface presenting device health and 
status information; 

FIG. 8 is a screen illustration of an exemplary graph- 
ical user interface provided by a policy manage- 
ment sub-module in the policy server of FIG. 3; 

FIG. 9 is a screen illustration of an exemplary graph- 
ical user interface for managing system devices; 

FIG. 10 is a screen illustration of an exemplary 
graphical user interface for managing system hosts; 

FIG. 11 is a screen illustration of an exemplary 
graphical user interface for managing system serv- 
ices; 

FIG. 12 is a screen illustration of an exemplary 
graphical user interface for managing time groups; 

FIG. 13 is a screen illustration of an exemplary 
graphical user interface displaying a plurality of 
VPN clouds; 

FIG. 14 is a screen illustration of an exemplary 
graphical user interface for adding a new firewall 
policy; 

FIG. 15 is a schematic functional block diagram of 
policy enforcers updating their respective VPN 
membership information; 



FIG. 19 is a more detailed schematic block diagram 
of a policy engine in the policy enforcer of FIG. 18; 

FIG. 20 is a more detailed schematic block diagram 
of a protocol classification engine of the policy en- 
forcer of FIG. 18; 

FIG. 21 is a more detailed schematic block diagram 
of an Internet protocol security engine in the policy 
enforcer of FIG. 18; 

FIG. 22 is a schematic layout diagram of a common 
log format according to one embodiment of the in- 
vention; 

FIG. 23 is a block diagram of an LDAP tree structure 



FIG. 16 is a block diagram of components in a self- 
extracting executable for downloading by a remote 
35 VPN client; 

FIG. 17 is a functional block diagram for download- 
ing the self-extracting executable of FIG. 16; 

40 FIG. 1 8 is a schematic block diagram of a policy en- 
forcer in the policy management system of FIG. 1 ; 
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according to one embodiment of the invention; 

FIG. 24 is a more detailed block diagram of a branch 
of the LDAP tree of FIG. 23; 

FIG. 25 is a flow diagram for logging and propagat- 
ing LDAP changes to policy enforcers; 

FIG. 26 is a schematic block diagram of a high avail- 
ability system including a primary unit and a backup 
unit; 

FIG. 27 is a flow diagram of an exemplary status 
discovery process conducted by a high availability 
unit; 

FIG. 28 is a flow diagram of a process for maintain- 
ing configuration information synchronized in the 
primary and backup units of FIG. 26; 

FIG. 29 is an exemplary flow diagram of updating 
the primary and backup units of FIG. 26 when they 
are both functional; and 

FIG. 30 is an exemplary flow diagram of updating 
the primary and backup units FIG. 26 when the pri- 
mary is not functional. 

DETAILED DESCRIPTION OF THE INVENTION 

I. UNIFIED POLICY MANAGEMENT SYSTEM 
ARCHITECTURE 

[0029] FIG. 1 is a schematic block diagram of an ex- 
emplary unified policy management system according 
to one embodiment of the invention. As illustrated in 
FIG. 1, private local networks 102, 104, and 106 are all 
coupled to a public network such as the Internet 108 via 
respective routers (generally identified at 110) and In- 
ternet Service Providers (ISPs) (not shown). Also cou- 
pled to the public Internet 108 via the ISPs are web surf- 
ers 112, dial-up network users 114, servers providing 
unauthorized web sites 1 1 6, email spammers 1 1 8 send- 
ing out unsolicited junk email, and remote VPN clients 
140 seeking access to the private local networks 102. 
[0030] According to one example, local network 102 
connects users and resources, such as workstations, 
servers, printers, and the like, at a first location of the 
organization, such as the organization's headquarters, 
and local network 104 connects users and resources at 
a second location of the organization, such as a branch 
office. Furthermore, local network 106 connects users 
and resources of a customer of the organization requir- 
ing special access to the organization's users and re- 
sources. Authorized dial-up network users 114 of the or- 
ganization are respectively situated at remote locations 
from the first and second local networks, and also re- 
quire special access to the organization's users and re- 



sources. Furthermore, web surfers 112 communicate 
with the organization's web server 120 over the public 
Internet 108 and access the organization's web site. 
[0031] Local network 102 includes a policy server 122 

5 for defining and managing network services and policies 
for the organization. The network policies are a set of 
rules and instructions that determine the network=s op- 
eration, such as firewall, VPN, bandwidth, and adminis- 
tration policies. The firewall policies decide the network 

10 traffic that is to be allowed to flow from the public Internet 
108 into the local networks 102, 104, and the traffic that 
is to be blocked. The bandwidth policies determine the 
kind of bandwidth that is to be allocated to the traffic 
flowing through the local networks. The VPN policies de- 

*5 termine the rules for implementing multiple site connec- 
tivity across the local networks. The administration pol- 
icies decide the users that have access to administrative 
functions, the type of administrative functions allocated 
to these users, and the policy enforcers 124. 126 on 

20 which these users may exercise such administrative 
functions. The firewall, VPN, bandwidth, and adminis- 
tration policies for the entire organization are preferably 
stored in a policy server database 130 maintained by 
the policy server 122. 

25 [0032] Each local network 102, 104 also includes an 
edge device, referred to as a policy enforcer 124, 126, 
for controlling access to the network. Each policy en- 
forcer 124, 126 manages the network policies and serv- 
ices for the users and resources of their respective local 

30 networks 102, 104, as permitted by the policy server 
122. Respective portions of the policy server database 
130 are copied to the policy enforcer databases 132, 
134 for allowing the policy enforcers to manage the net- 
work policies and services for the local networks 102, 

35 104. 

[0033] According to one embodiment of the invention, 
the policy server 122 and policy enforcers 124, 126 may 
be implemented in a similar fashion as the FORT KNOX 
series of policy routers made by Alcatel Internetworking, 
40 inc., of Milpitas, California. 

II. OBJECT MODEL FOR NETWORK POLICY 
MANAGEMENT 

45 [0034] According to one embodiment of the invention, 
the policy server database 130 and policy enforcer da- 
tabases 132, 134 are LDAP databases adhering to a 
unified hierarchical object oriented structure. The LDAP 
directory service model is based on entries where each 

50 entry is a collection of attributes referenced by a distin- 
guished name (DN). Each of the attributes includes a 
type and one or more values. The type is typically a mne- 
monic string, such as "o" for organization, "c" for country, 
or "mail" for email address. The values depend on the 

55 type of attribute. For example, a "mail" attribute may 
contain the value "babs@umich.edu." A "jpegPhoto" at- 
tribute may contain a photograph in binary JPEG/JFIF 
format. Additional details of the LDAP directory service 
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model are defined in RFC 1777 "The Lightweight Direc- 
tory Access Protocol" (W. Yeong, T. Howes, and Kille, 
Network Working Group, March 1995) and "LDAP Pro- 
gramming: Directory-enabled Applications with Light- 
weight Directory Access Protocol" (T. Howes, and M. 
Smith, Macmillan Technical Publishing, 1997), incorpo- 
rated herein by reference. 

[0035] The entries in the LDAP database are prefer- 
ably arranged in a hierarchical tree-like structure reflect- 
ing political, geographic, and/or organizational bounda- 
ries. Entries representing countries appear at the top of 
the tree. Below them are entries representing states or 
national organizations. Below the states or national or- 
ganizations may be entries representing people, organ- 
ization units, printers, documents, and the like. 
[0036] FIG. 2 is a schematic layout diagram of a uni- 
fied hierarchical object oriented structure adhered by 
the policy server database 1 30 according to one embod- 
iment of the invention. The policy enforcer databases 
132, 134 adhere to a similar structure except for a few 
differences. For example, the policy enforcer databases 
preferably do not contain a policy server domain object 
201 and related policy server objects, nor a policy do- 
main object 240. 

[0037] As illustrated in FIG. 2, each object in the struc- 
ture is preferably stored as an LDAP entry. At the top of 
the hierarchy is the policy server domain object 201 in- 
cluding various policy server resources and a plurality 
of policy domains objects (generally referenced at 204). 
Each policy domain object 240 is a grouping of policy 
enforcers that share common policies. Each policy do- 
main object 240 includes a resource root object 200 and 
a group root object 202. All policy management func- 
tions are preferably implemented in terms of the re- 
source objects which include devices 204, users 206, 
hosts 208, services 210, and time 220. Thus, a firewall 
policy may be defined by simply assigning the particular 
devices, users, hosts, services, and time applicable to 
the policy. The devices, users, hosts, and services are 
preferably organized in groups 212, 214, 216, and 218. 
respectively, having a group name, description, and 
member information for a more intuitive way of address- 
ing and organizing the resources. 
[0036] Users 206 are preferably associated with a us- 
er domain providing a secure and efficient means of au- 
thenticating the user. Each user domain has a single pol- 
icy enforcer who is authorized to authenticate the user. 
Thus, user domains ensure that the authenticating 
agent is generally located in the same local network as 
the user. This helps eliminate the cost of network de- 
pendency or network latency during the user authenti- 
cation process. It should be noted, however, that users 
may also constitute authorized dial-up users 114 and us- 
ers from the customer network 1 06. These users contact 
a remote authenticating agent which proxies the authen- 
tication back to the appropriate policy enforcer. 
[0039] Hosts 208 are the various networks present in 
an organization. For instance, a particular LAN subnet 



may be specified as a host in the system. Hosts 208 are 
preferably organized based on their physical locations 
within the organization. A host=s physical location is 
identified by the device (policy enforcer) 204 associated 

5 with the host. 

[0040] Services 210 reflect the various services pro- 
vided by the policy server 122. Such services include, 
for example, multimedia streaming/conferencing, infor- 
mation retrieval, security and authentication, database 

io applications, mail applications, routing applications, 
standard communication protocols, and the like. At- 
tributes associated with each service preferably include 
a service name, description, type (e.g. HTTP, HTTPS, 
FTP, TELNET, SMTP, Real Networks, and the like), and 

15 group. 

[0041] Devices 204 are the policy enforcers 124, 126 
at the edge of a particular local network. Each device/ 
policy enforcer preferably includes users 206 and a 
host/network 208 that is managed by the policy enforcer. 
[0042] Time 220 is another dimension in controlling 
access to the network resources. Various time objects 
covering a range of times may be created and used in 
creating the firewall policies. 

[0043] Similar to resources, network policies are also 
preferably defined in terms of objects for a more efficient 
and intuitive definition of the policies. Policies are de- 
fined by the administrators and implemented by the pol- 
icy enforcers 124, 126 on the network traffic flowing be- 
tween the public Internet 108 and the local networks 102 
and 104. 

[0044] According to one embodiment of the invention, 
a policy object 222 includes a bandwidth policy 224, fire- 
wall policy 226, administration policy 228, and VPN pol- 
icy 230. The VPN policy 230 defines a security policy 
for the member networks and includes one or more VPN 
clouds 232. Each VPN cloud 232 is an individual VPN 
or a group of VPNs defining a security policy group 
which includes a list of sites 234 and users 236 who can 
communicate with each other. A site is preferably a set 
of hosts/networks physically located behind one of the 
policy enforcers 124, 126. In other words, a site is a def- 
inition of a network which includes the policy enforcer 
that is associated with it. The policy enforcers for the 
sites act as VPN tunnel endpoints once the hosts under 
the sites start communicating. These communications 
are governed by a set of rules 238 configured for each 
VPN cloud. The rules 238 may govern, among other 
things, VPN access permissions and security features 
such as the level of encryption and authentication used 
for the connectivity at the network layer. 
[0045] The object oriented structure of FIG. 2 thus al- 
lows the network administrators to define policies in an 
intuitive and extensible fashion. Such policies may be 
defined by simply associating resources to the policies. 
This allows for a policy-centric management model 
where the administrator is given the impression that a 
single logical server provides the firewall, bandwidth 
management, and VPN services across the enterprise. 
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The fact that the policy is enforced on individual policy 
enforcers in different locations is transparent to the ad- 
ministrator. 

III. POLICY-BASED NETWORK ARCHITECTURE 

[0046] FIG. 3 is a more detailed schematic block dia- 
gram of the policy server 122 according to one embod- 
iment of the invention. The policy server 122 preferably 
includes a management module 302 that allows central- 
ized control over the policy enforcers 124, 126 from a 
single console. The policy server 122 further includes a 
log collecting and archiving module 304 and a policy 
server reports module 316. The log collecting and ar- 
chiving module 304 collects information about the status 
and usage of resources from the policy enforcers 124, 
126 as well as from the management module 302, and 
stores them in an archive database 31 8. The policy serv- 
er reports module 316 uses the collected logs and ar- 
chives to generate reports in an organized report format. 
[0047] Referring again to the management module 
302, the management module 302 preferably includes 
four sub-modules aiding in the centralized control, 
namely, a centralized management sub-module 306, 
policy management sub-module 308, secure role-based 
management sub-module 310, and multiple site con- 
nectivity management sub-module 312. 
[0048] The centralized management sub-module 306 
enables a network administrator to install and manage 
individual policy enforcers from a central location. The 
network administrator preferably uses a web-based 
graphical user interface to define the policy enforcer's 
network configuration and monitor various aspects of 
the device, such as device health, device alarms, VPN 
connection status, and the like. 
[0049] The policy management sub-module 308 pro- 
vides the network administrator with the ability to create 
policies that span multiple functional aspects of the pol- 
icy enforcer (e.g. firewall, bandwidth management, and 
virtual private networks), multiple resources (e.g. users, 
hosts, services and time), and multiple policy enforcers. 
[0050] The secure role-based management sub- 
module 310 provides role-based management to enable 
administrators to delegate administrative responsibili- 
ties to other administrators. This sub-module preferably 
provides for maximum security when it comes to ac- 
cessing the management functions. 
[0051] The multiple site connectivity management 
sub-module 312 allows the network administrator to set- 
up secure communication channels between two or 
more remote sites. In doing so, this sub-module lever- 
ages the centralized management sub-module 306, pol- 
icy management sub-module 308, dynamic routing ca- 
pabilities of the policy enforcers 124, 126, and the man- 
agement infrastructure to provide virtual private net- 
works across the enterprise with fine grained access 
control. 

[0052] FIG. 4 is a more detailed schematic diagram 



of the central policy management sub-module 306 ac- 
cording to one embodiment of the invention. The sub- 
module includes a policy server installation wizard 404 
providing an interactive user interface to aid the instal- 

5 lation of the policy server 1 22. In this regard, the network 
administrator has access to a personal computer con- 
nected to a LAN port of the policy server 1 22 via a cross 
over cable, hub, or the like. The network administrator 
connects to the policy server 122 by preferably typing- 

10 in a URL of the policy server 1 22 into a standard Internet 
browser such as Microsoft Internet Explorer. The URL 
is preferably of the form of 

"http://<ipaddress>:88/index.htmr where <ipaddress> 
is the IP address that is to be assigned to the policy serv- 

15 er. The IP address is automatically assigned to the pol- 
icy server when the browser attempts to contact the ad- 
dress. When the administrators personal computer 
sends an address resolution protocol request for the IP 
address, the policy server detects that a packet directed 

20 to port 88 is not claimed, and assumes the IP address. 
[0053] Once connected, the policy server installation 
wizard 404 invokes the interactive user interface to as- 
sist the administrator in setting up the policy server 122. 
Among other things, the policy server installation wizard 

25 404 prompts the administrator to specify a server name, 
server IP address, and router IP address. Furthermore, 
the policy server installation wizard 404 prompts the ad- 
ministrator to select one of various default policies for 
creating default firewall, VPN, bandwidth, and adminis- 

30 trator policies. These policies are then replicated on 
each new policy enforcer registering with the policy 
server 122. 

[0054] The centralized management sub-module 306 
further includes a policy enforcer installation wizard 406 

35 providing an interactive user interface to aid the instal- 
lation of the policy enforcers 124, 126. As with the in- 
stallation of the policy server 1 22, the access to the wiz- 
ard 406 is preferably web-based using the network ad- 
ministrator's personal computer. 

40 [0055] Once connected, the policy enforcer installa- 
tion wizard 406 invokes the interactive user interface to 
assist the network administrator in setting up a particular 
policy enforcer 124, 126. Among other things, the policy 
enforcer installation wizard 464 prompts the administra- 

45 tor to specify the policy server IP address, policy enforc- 
er IP address, and router IP address. The policy enforc- 
er then registers with the policy server 122 by invoking 
a URL on the policy server with basic bootstrap infor- 
mation of its own. The registration of the policy enforcer 

50 allows the initialization of the policy enforcers data- 
base 1 32, 1 34 with the configuration information, as well 
as the monitoring of the policy enforcer's status and 
health by the policy server 1 22. 
[0056] Prior to registering the policy enforcer with the 

55 policy server 1 22, the network administrator preferably 
pre-registers the policy enforcer on the policy server. 
Such preregistering allows the creation of a placeholder 
node on the policy server for the policy enforcer data for 
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when the policy enforcer does in fact register In this re- 
gard, the centralized management sub-module 306 in- 
cludes a configuration interface 410 allowing the pre- 
registration of a new policy enforcer. 
[0057] FIG. 5 is an exemplary flow diagram of a policy 
enforcer pre-registration and registration process ac- 
cording to one embodiment of the invention. In step 401 , 
the policy enforcer is connected to the network and in- 
stalled at its actual physical location using the above- 
described policy enforcer installation wizard 406. The 
network administrator, possessing the new device's se- 
rial number, pre-registers the policy enforcer by adding 
the new policy enforcer to a device group in step 403. 
In this regard, the configuration interface 410 invokes 
an interactive graphical interface, such as the one illus- 
trated in FIG. 6, allowing the network administrator to 
enter a device name 415. serial number 417, and loca- 
tion information 419, and further allowing the adminis- 
trator to select a device group 421 to which the new pol- 
icy enforcer is to belong. Actuation of an apply button 
423 causes the new policy enforcer, in step 405, to con- 
tact the policy server 122 by preferably invoking a URL 
on the policy server. Once the policy server has been 
contacted, the new policy enforcer transmits its regis- 
tration packet to the policy server. The registration pack- 
et includes at least a serial number of the new policy 
enforcer, as well as the IP addresses of the LAN, WAN, 
and DMS on the policy enforcer. In step 407, the cen- 
tralized management sub-module 306 compares the se- 
rial number of the new policy enforcer with the list of 
policy enforcers pre-registered with the policy server 
122. If a match is found, the policy server 122 proceeds 
with the registration process by packaging, in step 409, 
the settings selected for the policy enforcer during its 
installation process, preferably into an LDAP Data Inter- 
change Format (Idif) file. In step 411 , the file is transmit- 
ted to the policy enforcer, preferably over an HTTPS 
channel, by invoking a common gateway interface (CGI) 
on the policy enforcer. The policy enforcer then uses the 
file to initialize its configuration database, such as data- 
base 132, 134, in step 413. 

[0058] Referring again to FIG. 4, the centralized man- 
agement sub-module 306 also includes a global monitor 
user interface 402 and a data collector program 41 2, re- 
spectively displaying and collecting the health and sta- 
tus of all the policy enforcers managed by the policy 
server 122. The data collector program 412 receives 
health and status information from each of the up-and- 
running policy enforcers it manages, and passes the rel- 
evant information to the global monitor user interface. A 
health agent running as a daemon in each of the policy 
enforcers being monitored periodically collects data 
from the device and analyzes its health status. The col- 
lected data is then transferred to the policy server 122 
when requested by the data collector program 412. 
[0059] FIG. 7 is a screen illustration of an exemplary 
global monitor user interface 402 presenting various 
types of health and status information. Such information 



may relate to the health of the device, such as system 
load 712 and network usage information 714. The infor- 
mation may also relate to current alarms 71 6 on the de- 
vice including alarm name, type, description, and the 

5 like. The information may further relate to current VPN 
connections 718 including connection type, source/des- 
tination, duration, and VPN traffic volume. 
[0060] Referring again to FIG. 3, the policy manage- 
ment sub-module 308 allows for policy management of 

10 the policy enforcers 124, 126. As discussed above, all 
policy management functions are implemented in terms 
of resource objects stored in the policy databases 1 30, 
132, 134 including users, devices, hosts, services, and 
time. Preferably, all resources are associated with de- 

15 fault policy settings selected by the administrator during 
the installation process. The network administrator 
views, adds, and modifies the policies centrally via a 
graphical user interface provided by the policy manage- 
ment sub-module 308. This allows for a policy-centric 

20 management model where the administrator is given the 
impression that a single logical server provides the fire- 
wall, bandwidth management, and VPN services across 
the enterprise. The fact that the policy is enforced on 
individual policy enforcers in different locations is trans- 

25 parent to the administrator. 

[0061] FIG. 8 is a screen illustration of an exemplary 
graphical user interface provided by the policy manage- 
ment sub-module 308. The interface includes a re- 
source palette 718 including a list of resource tabs in-. 

30 eluding a users tab 718a, devices tab 718b, hosts tab 
718c, services tab 718d, and time tab 718e. The re- 
source palette allows the administrator to add and mod- 
ify resource definitions from a single console. 
[0062] Selection of the users tab 718a causes a dis- 

35 play of the user groups 722 defined for the system. New 
users may be added to the group by selecting a partic- 
ular group and defining various attributes of the user 
such as a login name, full name, policy enforcer to which 
the user belongs, authentication scheme, password, 

40 and the like. 

[0063] Selection of the devices tab 7 1 8b causes a dis- 
play of various device management icons for managing 
the policy server 122 and the policy enforcers 124, 126 
as is illustrated in FIG, 9. A policy server systems set- 

45 tings icon 750 allows the network administrator to view 
and modify system settings like LAN, WAN/DMS IP ad- 
dresses of the policy server 122. A policy server archive 
options icon 752 allows specification of reporting and 
other database archive options at the policy server 122. 

50 A global URL blocking icon 754 allows the administrator 
to specify a list of unauthorized web sites 116 to be 
blocked by all the policy enforcers 124, 126 of the sys- 
tem. Similarly, a global spam list icon 756 allows the ad- 
ministrator to specify a list of email addresses of spam- 

55 mers 118 to be blocked by all the policy enforcers. 
[0064] The administrator may view information on all 
the policy enforcers 124, 126 by selecting icon 758. In- 
formation on a specific policy enforcer may be viewed 
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by selecting a specific policy enforcer 760 under a par- 
ticular device group 761 . Such information includes sys- 
tem settings information 762, URL blocking information 
764, spam list information 766, and the like, that is spe- 
cific to the selected policy enforcer. For instance, selec- 5 
tion of the policy enforcer's URL blocking information 
764 icon causes a display of various categories 768 of 
URLs that the network administrator may select to block 
for the selected policy enforcer. 
[0065] Selection of the hosts tab 718c causes a dis- 
play of various hosts (networks) of the system as is il- 
lustrated in FIG. 10. A host is organized based on its 
physical location and is further associated with a partic- 
ular policy enforcer 124, 126. Hosts are associated with 
various attributes including a unique name 770, an IP 
address of the network 772, and a subnet mask 774. In 
addition, the administrator may specify whether the host 
is an external host 776 belonging to a network that is 
not administered by the policy server 122. If the host is 
an external host, the administrator specifies an IP ad- 
dress 778 of the external device to which the host be- 
longs. A device field 780 allows the administrator to en- 
ter the policy enforcer's name to which the host belongs. 
Each host is further associated with a particular group 
782 assigned by the administrator. 
[0066] Selection of the services tab 718d causes a 
display of various service groups supported by the pol- 
icy server 122 as is illustrated in FIG. 11. Such service 
groups include, for example, multimedia streaming/con- 
ferencing, information retrieval, security and authentica- 
tion, mail applications, routing applications, database 
applications, standard communication protocols and the 
like. Users may also add new service groups as desired. 
[0067] Each service is associated with a name 784, 
description 786, and service type 788 (e.g. HTTP, HT- 
TPS, FTP, TELNET, SMTP, Real Networks, and the 
like). Furthermore, each service is associated with a 
service group 790. Based on the type of service, addi- 
tional information may also be specified for the service. 
For instance, for an HTTP service, the administrator 
may specify whether URL blocking 792 is to be enabled. 
[0068] Selection of the time tab 71 8e causes a display 
of various time group icons 794 covering a range of 
times to be used in the firewall policies as is illustrated 
in FIG. 12. For instance, selection of a work time group 
icon allows the network administrator to set the days and 
times which are to be set as working days and hours. 
[0069] Referring again to FIG. 8, the interface also in- 
cludes a policy canvas 720 including a list of policies 
available to the system. A policy definition is preferably 
an association of a set of resources that may be dragged 
from the resource palette 718 and dropped onto the pol- 
icy canvas 720. 

[0070] Selection of a firewall tab 720a causes a dis- 
play of ail the firewall policies defined for a particular 
policy domain including one or more policy enforcers. 
The network administrator decides the domain to which 
a policy enforcer is to belong during pre-registration of 



the policy enforcer. The interface allows the network ad- 
ministrator to view, add, and modify the various policies 
from the policy server 122 and effectuate the changes 
on the policy enforcers 124, 126 without the need to 
make such changes individually in each policy enforcer 
[0071] According to one embodiment of the invention, 
each firewall policy includes a policy identifier (ID) at- 
tribute 724 for identifying a particular policy rule in the 
list of policies. An order number attribute 726 for the pol- 
icy rule indicates the sequence in which the policy is to 
be applied. In this regard, the policy enforcer 124, 126 
for the local network takes one rule at a time, in se- 
quence, compares it against the network traffic, and 
preferably applies the first rule that matches the network 
traffic. 

[0072] Each firewall policy also includes a description 
attribute 728 for describing the firewall policy to be ap- 
plied. For instance, the description may indicate that the 
policy allows spam blocking, URL blocking, VPN key 
management, and the like. An action flag attribute 730 
indicates whether traffic is to be allowed or denied for 
the indicated policy. An active flag attribute 732 indi- 
cates whether the policy has been activated or de-acti- 
vated. Thus, the network administrator may create a pol- 
icy and activate it at a later time. A policy that has been 
de-activated preferably has no effect on the network 
traffic. 

[0073] Each firewall policy further includes a user at- 
tribute 734, source attribute 736, service attribute 738, 
destination attribute (not shown), and time attribute (not 
shown). Each of these attributes is preferably represent- 
ed by a group name or a resource name. The name acts 
as a pointer to an entry in the group root object 202 or 
resource root object of the LDAP database 130, 132, or 
134. 

[0074] Preferably, the user attribute 734 indicates the 
user groups and users that are eligible for the policy. 
The source attribute 736 indicates a point of origination 
of the network traffic associated with the user. The serv- 
ices attribute 738 indicates the services to the allowed 
or denied by the policy. The destination attribute indi- 
cates a specific LAN, WAN, DMS segment or specific 
hosts where the specified services are to be allowed or 
denied. For example, to configure SMTP pop services 
on a mail server, the host may be the IP address where 
the mail server is running, and the services specified is 
SMTP. The time attribute indicates a time slot in which 
the policy is to be effective, 

[0075] In addition to the above each firewall policy al- 
so includes an authentication attribute (not shown) indi- 
cating an authentication scheme for the policy (e.g. 
none, LDAP, SecurlD, RADIUS, WinNT, or all). 
[0076] FIG. 14 is a screen illustration of an exemplary 
graphical user interface for adding a new firewall policy 
to the policy domain upon actuation of an add button 
725. Existing firewall policies may also be modified or 
deleted by actuation of a modify button 727 and a delete 
button 729, respectively. 
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[0077] As illustrated in FIG. 14, a new firewall policy 
may be defined by simply adding a description of the 
policy in a description area 728a, selecting an action to 
be applied to the matching network traffic in an action 
box 730a, and indicating in an active area 732a whether 5 
the policy is to be active or inactive. Furthermore, the 
network administrator specifies the user, source, serv- 
ices, destination, and time resources in a user area 
734a, source area 736a, services area 738a, destina- 
tion area 739a, and time area 741 , respectively. The net- 
work administrator further selects an authentication 
scheme for the policy in an authentication area 743. Up- 
on actuation of an OK button 745, appropriate entries of 
the policy server database's LDAP tree are suitably 
changed to reflect the addition of the new policy. The 
change is also transmitted to the respective policy en- 
forcers as is described in further detail below. 
[0078] Referring again to FIG. 8, selection of the 
bandwidth tab 720c allows the display, addition, and 
modification of various bandwidth policies determining 
the kind of bandwidth to be allocated to a traffic flowing 
through a particular policy enforcer. Different band- 
widths may be specified for different users, hosts, and 
services. 

[0079] Selection of the administration tab 720d allows 
the display, addition, and modification of various admin- 
istrative policies allowing a head network administrator 
to delegate administrative responsibilities to other ad- 
ministrators. In this regard, the head network adminis- 
trator specifies administration policies that determine 
which users have access to what functions, and for what 
devices. Preferably the administration policies include 
similar attributes as the firewall rules except for the 
specification of a role attribute. Extra administrative priv- 
ileges may be afforded to certain users depending on 
their role. 

IV. VIRTUAL PRIVATE NETWORK HAVING 
AUTOMATIC REACHABILITY UPDATING 

[0080] Referring again to FIG. 3, the multi-site con- 
nectivity management module 312 allows the creation 
of dynamically routed VPNs where VPN membership 
lists are automatically created without statically config- 
uring the membership information by the network ad- 
ministrator. Thus, once the administrator configures a 
VPN from one policy enforcer's LAN to another, routing 
protocols such as RIPvl or RIPv2 running on the LAN 
interfaces leam about the networks reachable through 
their respective interfaces. These networks then be- 
come the VPN's members, and the policy enforcers 1 24, 
1 26 on either side of the VPN create membership tables 
using the learned routes. The membership information 
is preferably exchanged between the policy enforcers 
124, 126 through the LDAP databases 132, 134. Thus, 
the combined use of routing protocols and LDAP allows 
the creation of VPNs whose member lists are dynami- 
cally compiled. 



[0081] Referring again to FIG. 8, the network admin- 
istrator configures VPN policies for multiple site connec- 
tivity using the resource palette 718 and policy canvas 
720. Selection of the VPN tab 720b in the policy canvas 
720 causes the display of a collection of VPN clouds 
270 already configured for the system as is illustrated 
in FIG. 13. As described above, a VPN cloud is an indi- 
vidual VPN or a group of VPNs for which a security pol- 
icy may be defined. Each VPN cloud includes a list of 
sites under a sites node 234 and users under a users 
node 236, who can communicate with each other. A site 
is a set of hosts that are physically behind one of the 
policy enforcers 124, 126. The policy enforcers for the 
sites preferably act as VPN tunnel endpoints once the 
hosts under the sites start communicating. 
[0082] The users in the VPN cloud are the users who 
may access the hosts associated with the sites 234. The 
users access the hosts as VPN clients using VPN client 
software installed in each user's personal computer as 
is described in further detail below. 
[0083] Each VPN cloud 270 further includes a firewall 
rules node 276 including firewall rules to be applied all 
the connections in the cloud. The rules may govern, 
among other things, VPN access permissions, security 
features such as the level of encryption and authentica- 
tion used for the connectivity at the network layer. 
[0084] The hierarchical organization provided by the 
VPN clouds thus allows the network administrator to 
create fully meshed VPNs where every site within a VPN 
cloud has full connectivity with every other site. The net- 
work administrator need no longer manually configure 
each possible connection in the VPN, but only need to 
create a VPN cloud and specify the sites, users, and 
rules to be associated with the VPN. Each connection 
is then configured based on the configuration specified 
for the VPN cloud. The hierarchical organization thus 
facilitates the setup of a VPN with a large number of 
sites. 

[0085] The network administrator preferably adds a 
new VPN cloud by actuating an add button 280. In re- 
sponse, the policy server 122 automatically creates the 
sites node 272, users node 274, and rules node 276 un- 
der the VPN cloud. The administrator then specifies the 
sites and users in the VPN. 

[0086] According to one embodiment of the invention, 
the rules node 276 initially includes a default VPN rule 
278 corresponding to the policy settings selected by the 
network administrator during setup of the policy server 
122. The default VPN rule 278 allows unrestricted ac- 
cess between the hosts in the VPN. 
[0087] The administrator may implement the access 
control within the VPN cloud by deleting the default rule 
278 and adding specific firewall rules to the VPN. Such 
firewall rules allow the administrator to have fine grained 
access control over the traffic that flows through the 
VPN, all within the realm of the encrypted access pro- 
vided by such VPN. The firewall rules are applied to the 
cleartext packet after it is decrypted or before it is en- 
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crypted. 

[0088] According to one embodiment of the invention, 
the administrator selects the default rule 278 to effectu- 
ate such changes to the default rule. Selection of the 
default rule invokes a graphical user interface similar to 
the one illustrated in FIG. 8. The network administrator 
then fine tunes the access to the VPN by defining the 
firewall rules applicable to the VPN. The parameters in 
these firewall rules are preferably identical to the gen- 
eral firewall rules illustrated in FIG. 8. 
[0089] Once a VPN cloud is configured, VPN mem- 
bership information is dynamically created by the policy 
enforcers 124, 126 in the VPN. In this regard, each VPN 
site includes a tag identifying the hosts included in the 
site. At runtime, the policy enforcers 124, 126 for the 
respective sites associate IP addresses to the tag iden- 
tifying the hosts in each site. This allows the IP address- 
es to be dynamically discovered without requiring static 
configuration of the IP addresses. 
[0090] After the creation of the membership tables, 
any changes in the routing information is detected and 
notified to the member policy enforcers using a publish/ 
subscribe process. The actual changes are retrieved by 
a policy enforcer by querying the LDAP database on the 
particular network that corresponds to the changed rout- 
ing information. 

[0091] FIG. 15 is a schematic functional block dia- 
gram of policy enforcers 124, 126 at opposite ends of a 
VPN tunnel updating their respective routing informa- 
tion. As illustrated in FIG. 15, each policy enforcer 124, 
126 includes a gated module 252, 261 configured as a 
daemon to run one or more routing protocols for ex- 
changing routes on the network. Such routing protocols 
may include RIPvl , RIPv2, OSPF, and the like. 
[0092] When a network administrator wishes to add a 
new route to the private local network 102 connected to 
policy enforcer 124, the administrator submits, in step 
241 , the new route to a gated module 252 in the policy 
enforcer 124. This is typically done by configuring a 
downstream of the policy enforcer to have an additional 
network. This information is then propagated by stand- 
ard routing protocols to the gated module 252 of the pol- 
icy enforcer 124. For example, the policy server 122 
may publish the new route to the policy enforcer 124 
with which the new route is to be associated. The route 
may be specified, for example, by an LDAP statement 
such as "LAN_Group@PRV which specifies a new 
route from a policy enforcer PR1 to a LAN named 
LAN_Group. The gated module 252, in step 242, writes 
the new route to a kernel 253 of the policy enforcer in- 
cluding a VPN driver 254 so that the policy enforcer 124 
can properly direct appropriate messages along the new 
route. Furthermore, the gated module 252, in step 243, 
writes the new route to its LDAP database 1 32. 
[0093] The gated module 252 also provides, in step 
244, the name of the new route to a distinguished name 
monitor (DNMonitor) daemon 255 configured to listen 
for updates in the LDAP database 132. The DNMonitor 



in turn notifies, in steps 245a, 245b, a VPN daemon 256 
and a policy deployment point (PDP) engine 257 of the 
change in the LDAP database 132. The PDP engine 
then updates the modules that enforce the policies, with 
5 the change. 

[0094] The VPN daemon 256, in step 246, uses the 
route name to access the LDAP database 1 32 to get the 
complete route information, a list of all VPNs to which 
the new route belongs, and a list of all other policy rout- 
to ers connected to those VPNs. In step 247, the VPN dae- 
mon 256 proceeds to send the new route name to each 
of the other policy routers. 

[0095] When policy router 126 receives a new route 
name from policy router 124, its network daemon 258, 
15 in step 248, accesses the LDAP database 132 in the 
sending policy router 124 to obtain the complete new 
route information. If the new route belongs to more than 
one VPN and has different parameters for the different 
VPNs, routers on the different VPNs retrieve different 
information corresponding to the individual VPNs. 
[0096] In step 249, the network daemon 258 writes 
the new route information obtained in its own LDAP da- 
tabase 1 34 and provides it to its own DNMonitor module. 
As in the sending policy router 1 24, the DNMonitor mod- 
ule 259 in the receiving policy router 126 provides the 
new route information to its PDP engine 260 for updating 
its kernel 265 with the latest changes. 
[0097] Although FIG. 15 has been described in con- 
nection with addition of a route to a policy enforcer and 
its associated VPNs, it should be readily apparent to 
those skilled in the art that essentially the same tech- 
niques may be applied to deletion of a route (for exam- 
ple, if a network component becomes inoperative or in- 
communicative), or change of a route (the policy router 
may recognize that a route already exists in a different 
form and simply overwrite it). In this way, the VPN sys- 
tem or systems can dynamically maintain routing infor- 
mation between its policy enforcers with minimal inter- 
vention by the system administrator. 

V. VIRTUAL PRIVATE NETWORK HAVING 
AUTOMATIC UPDATING OF CLIENT REACHABILITY 
INFORMATION 

[0098] Remote users communicate over the public In- 
ternet 108 with the other members of the VPN behind 
policy enforcers 124, 126, upon presenting appropriate 
credentials. These remote users access the private net- 
works as VPN clients 140 using a VPN client software. 
According to one embodiment of the invention, the sys- 
tem allows the remote user to download a self-extracting 
executable which, upon execution, installs both the VPN 
client software and VPN reachability information unique 
to the remote user in the user's remote terminal. 
[0099] Each policy enforcer 1 24, 126 preferably main- 
tains a copy of the self-extracting executable of the VPN 
client software including a setup program and VPN 
reachability configuration template. The setup program 
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allows the VPN client software to be installed on the 
VPN client 140. When downloading the self-extracting 
executable, the configuration template is replaced with 
the VPN reachability information that is specific to the 
downloading user. 

[01 00] According to another embodiment of the inven- 
tion, the system allows the VPN client 140 to download 
a self-extracting executable which, upon execution, only 
installs the VPN reachability information that is unique 
to the user. According to this embodiment, the VPN cli- 
ent software is already installed on the VPN client 140. 
In this scenario, the setup program allows the installa- 
tion of the reachability information that is specific to the 
downloading user, on the VPN client 140. 
[0101] According to a third embodiment of the inven- 
tion, the system allows the VPN client 140 to automati- 
cally download the VPN reachability information each 
time it connects to the policy enforcer 124, 126. Thus, 
VPN reachability information is kept up-to-date for each 
VPN client 140. Once a VPN session is established, the 
connection between the VPN client 140 and the policy 
enforcer is assumed to already be secure. The VPN cli- 
ent preferably makes a common gateway interface 
(CGI) query to a web server running on the policy en- 
forcer, and downloads the current VPN reachability in- 
formation from the corresponding LDAP database. 
[01 02] FIG. 1 6 is a block diagram of components in a 
self-extracting executable 290 according to one embod- 
iment of the invention. The self-extracting executable 
290 may be created using commercially available tools 
such as the INSTALLSHIELD EXEBUILDER of In- 
stallShiled Software Corporation of Schaumburg, Illi- 
nois. 

[0103] The self-extracting executable 290 preferably 
includes an executable setup file 292 for installing the 
VPN client software and/or the VPN configuration infor- 
mation. The setup file 292 preferably forms a static por- 
tion 298 of the self-extracting executable since this in- 
formation does not change based on the downloading 
VPN client. The self-extracting executable 290 further 
includes VPN configuration file templates for the VPN 
reachability information 294 and the VPN client's pre- 
shared key information 296. The VPN reachability infor- 
mation 294 and the VPN client's preshared key 296 pref- 
erably form a dynamic portion 299 of the self-extracting 
executable 290 since this information changes based 
on the downloading VPN client. The self-extracting ex- 
ecutable 290 is then saved as a template file in the policy 
enforcers 124, 126 and is ready to the downloaded by 
the remote users. 

[01 04] FIG. 1 7 is a functional block diagram for down- 
loading the self-extracting executable 290 of FIG. 16 ac- 
cording to one embodiment of the invention. In step 320, 
a new VPN client 140 first establishes a secure commu- 
nication session with the policy enforcer 124, 126 to 
download the self-extracting executable 290. Prefera- 
bly, this is accomplished via an HTTPS protocol session 
on the VPN client's web browser or the like. In steps 322 



and 324, the policy enforcer engages the VPN client in 
an authentication procedure where the policy enforcer 
requests, and the VPN client provides, his or her user 
name and password. In step 326, the policy enforcer 

5 compares the provided information with entries in its 
VPN client database 328. If the information is correct, 
the policy enforcer finds appropriate preshared keys for 
the user, and in step 330, also determines the VPN 
reachability information of the client from a VPN config- 

10 uration database 332. The VPN client database 328 and 
VPN configuration database 332 may reside as part of 
a single LDAP database 312, 314 managed by the pol- 
icy enforcer 124, 126, or may constitute separate LDAP 
databases. 

*5 [0105] In step 334, the policy enforcer replaces the 
dynamic portion 299 of the self-extracting executable 
290 with the VPN reachability information and pre- 
shared key that is unique to the VPN client. The newly 
generated self-extracting executable is then download- 

20 ed to the VPN client 140 in step 336. When the execut- 
able is run, it either installs the VPN client software and/ 
or the VPN reachability information. 
[01 06] Similar techniques may also be used for down- 
loading a new and updated copy of the VPN configura- 

25 tion information to the VPN client each time the client 
connects to the policy enforcer and negotiates a session 
key. In addition, the user may obtain the latest configu- 
ration of the VPN network by expressly requesting the 
policy enforcer for such information. Thus, the VPN cli- 

30 ent need not be reinstalled and reconfigured each time 
updates are made to the VPN reachability information. 

VI. INTEGATED POLICY ENFORCER 

35 [01 07] According to one embodiment of the invention, 
the functionalities of the policy enforcer 1 24, 1 26 for pol- 
icy enforcement are partitioned for effective hardware 
implementation. However, it should be apparent to one 
skilled in the art that some or all of the functionalities 

<o may be implemented in software, hardware, or various 
combinations thereof. 

[0108] FIG. 18 is a schematic block diagram of the 
policy enforcer 124, 126 illustrating the partitioning of 
the various functionalities according to one embodiment 

45 of the invention. The policy enforcer includes an Internet 
protocol security (IPSec) engine 502 for performing se- 
curity and authentication functions in implementing, for 
instance, virtual private networks. A stream table 506 
assembles the packets passing through the policy en- 

50 forcer into streams. A protocol classification engine 508 
decodes the protocols used in forwarding the packets. 
A policy engine 510 enforces policies for the packets 
based on the policy settings stored in the policy data- 
base 132, 134. A packet forwarding module 504 re- 

55 ceives packets from the public Internet via the router 110 
and buffers, forwards, or drops the packets based on 
the policies being enforced. A bandwidth management 
module 514 provides bandwidth shaping services to the 
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packets being forwarded based on the bandwidth set- 
tings stored in the policy database 132, 134. 
[0109] In practice, an incoming packet is matched 
against the stream table 506 for determining if a match- 
ing entry already exists in the table. If not, a new entry 
is added. The stream table preferably includes enough 
portions of the packet to uniquely identify a stream. For 
example, in enforcing policies on IP layer three through 
layer four traffic, the stream table may store a source IP, 
destination IP, source port, destination port, and proto- 
col number of the incoming packet. 
[0110] The protocol classification engine 508 takes 
the new stream and obtains a detailed protocol decode 
for the stream. The policy engine 510 is then queried for 
the policy rules to be applied to the stream. Based on 
the policy rules returned by the policy engine 510, the 
packet forwarding module 504, IPSec engine 502, and/ 
or the bandwidth management module 514 process the 
streams accordingly. The processing may be recursive 
until the packets in the stream have had all the actions 
specified by the policy rule set applied to them. 
[0111] The policy enforcer also includes a statistics 
module 512 for collecting statistics on the packets for- 
warded through the local network as well as other status 
and resource usage information, and provides the same 
in logs and archives for sending to the policy server 1 22. 
According to one embodiment of the invention, the sta- 
tistics module 512 keeps running byte counts of the 
packets passing through the network 102, 104. These 
byte counts may be automatically sorted by classes, 
such as classes based on certain resources (e.g. users, 
hosts, services), as well as by bytes that are blocked by 
policies and exceptions, such as firewall policies. In this 
regard, the statistics module 512 maintains in a cache 
a state table including a list of resources involved for 
each connection allowed through the firewall. For every 
packet flowing through the connection, the statistics 
module increments the packet and byte count for each 
of the resources in the list. The statistics module 512 
then forwards the organized information to the policy 
server 1 22 which enters the information directly into ta- 
bles organized by classes and aged out periodically. 
[0112] FIG. 19 is a more detailed schematic block di- 
agram of the policy engine 510 according to one em- 
bodiment of the invention. The policy engine 510 in- 
cludes a policy request table 602 that acts as a queue 
for ail the policy decision requests. In this regard, the 
portion of the packet matching the information stored in 
the stream table 506 is presented to the policy engine 
51 0 in the form of a policy request. The policy request 
is then queued in the policy request table 602. 
[0113] A resource engine 604 maintains an up-to- 
date mapping of resource group names to member 
mappings. A policy rules database buffer 608 stores a 
current policy rule set to be applied by the policy engine 
510. The policy rules stored in the buffer 608 are pref- 
erably in the original group-based rule specification for- 
mat. Thus, the buffer 608 stores a rule created for a 



group in its group-based form instead of instantiating a 
rule for each member of the group. 
[0114] A decision engine 606 includes logic to serve 
the incoming policy decision requests in the policy re- 
5 quest table 602 by matching it against the policy rule set 
in the policy rules database buffer 608 based on the ac- 
tual membership information obtained from the re- 
source engine 604. The relevant group-based rule 
matching the traffic is then identified and decision bits 
10 in the stream table set for enforcing the corresponding 
actions. The decision bits thus constitute the set of ac- 
tions to be performed on the packets of the stream. All 
packets matching the streams are then processed 
based on these decision bits. The decision engine may 
is also specify an access control list (ACL) including a set 
of rules that allow/deny traffic, a DiffServ standard for 
providing a quality of service level to the traffic, and/or 
VPN implementation information. 
[01 1 5] FIG. 20 is a more detailed schematic block di- 
agram of the protocol classification engine 508 accord- 
ing to one embodiment of the invention. As illustrated in 
FIG. 20, the protocol classification engine 508 includes 
a stream data assembly 702, a sliding stream data win- 
dow 704, an ASN.1 block 706, a protocol classification 
state machine 708, and a protocol definition signature 
database 710. The stream data assembly 702 extracts 
and re-assembles the data portion of an input packet 
stream and stores it in the sliding stream data window 
704. Preferably, the sliding stream data window follows 
first-in-first-out protocols. The ASN.1 decoder further 
decodes the data stream, if needed, per conventional 
ASN.1 encoding/decoding standards. The protocol 
classification state machine 708 then matches the fully 
re-assembled and decoded data against the protocol 
definition signature database 710. This database 710 
preferably holds a mapping of protocol names to data 
patterns to be found in the data stream. The matched 
protocol is then returned to the stream table 506. 
[0116] Thus, the protocol classification engine 508 
provides extensive layer three through layer seven pro- 
tocol decode and packet classification, including com- 
plete identification of dynamic streams using a dynam- 
ically updated signature database compiled from script- 
ed protocol definitions. As new protocols are defined in 
the future and/or users create their own custom appli- 
cations with custom protocols, a need may arise to add 
recognition of these protocols to the protocol classifica- 
tion engine. The described protocol classification en- 
gine architecture allows such additions by simply adding 
a new scripted definition of the new protocol to the pro- 
tocol classification engine without having to change the 
design each time a new protocol is added. This allows 
for custom protocol support and future protocol exten- 
sibility. 

[0117] FIG. 21 is a more detailed schematic block di- 
agram of the IPSec engine 502 according to one em- 
bodiment of the invention. As illustrated in FIG. 21, the 
IPSec engine 502 includes a Pseudo-Random Number 
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Generator (PRNG) function 802 for generating random 
numbers used for cryptographic key generation accord- 
ing to well known methods. A Diffie Hellman 804 and 
RSA 812 blocks implement the corresponding asym- 
metric public key encryption/decryption/signature algo- 
rithms which are also well known in the art. An IKE block 
806 communicates with an IPSec SA table 808 for im- 
plementing standard ISAKMP/Oakley(IKE) key ex- 
change protocols. A cryptographic transforms block 81 4 
implements standard symmetric encryption/decryption 
algorithms. An IPSec 

Encapsulation/Decapsulation block 810 performs 
standard encapsulation/decapsulation functions. Ac- 
cordingly, the IPSec engine 502 provides mature, stand- 
ards-based IKE/IPSec implementation with public key 
certificate support and necessary encryption/decryption 
functionality for packets passing through the private lo- 
cal networks 102, 104. 

VII. NETWORK POLICY LOGS AND STATISTICS 
AGGREGATION 

[01 18] Referring again to FIG. 3, the log collecting and 
archiving module 304 collects information about the sta- 
tus and usage of resources from the policy enforcers 
124, 126 as well as from the management module 302, 
and stores them in the archive database 31 8. The policy 
server reports module 316 then uses the collected logs 
and archives to generate reports in an organized report 
format. 

[0119] According to one embodiment of the invention, 
each policy enforcer 124, 126 maintains a log file with 
information collected about the flow of traffic through the 
policy enforcer as well as the status and usage of re- 
sources associated with the policy enforcer. All the log 
files follow a predefined common log format, preferably 
designed to create compact logs. 
[0120] FIG. 22 is a schematic layout diagram of such 
a log format according to one embodiment of the inven- 
tion. Each log entry includes a timestamp 820 in the for- 
mat yyyymmddhhmmss, indicative of the year, month, 
date, hours, minutes, and seconds in which the log entry 
was created. A service field 822 indicates the type of 
service rendered by the policy enforcer 124, 126. Such 
services include VPN, FTP, Telnet, HTTP, packet filter, 
bandwidth, and the like. Each log entry further includes 
a source IP address and port 824 indicating the source 
from where a packet was received, as well as a desti- 
nation IP address and port 826 indicating the destination 
to which the packet was forwarded. 
[0121] A user ID field 828 identifies the user transmit- 
ting the packet. The user ID may be mapped to an entry 
in the LDAP database 1 30, 1 32, or 1 34 for obtaining ad- 
ditional details about the user. 
[0122] A status field 830 indicates the status of an op- 
eration and may include a result code, error code, and 
the like. For example, for a packet filter service, the sta- 
tus field may include a result code "p" if the packet was 



passed or code "b" if the packet was blocked. 
[0123] An operation field 832 indicates codes for a 
type of operation conducted by the service. For in- 
stance, operations for a VPN service may include send- 
5 ing packets and receiving packets. Operations for an 
FTP service may include GET and PUT operations. Op- 
erations for an HTTP service may include GET and 
POST operations. 

[0124] In addition to the above, each log entry in- 
fo eludes an in-bytes field 832 indicative of the number of 
bytes the policy enforcer received as a result of the ac- 
tivity, and an out-bytes field 834 indicative of the number 
of bytes transferred from the policy enforcer. Further- 
more, a duration field 836 indicates the duration (e.g. in 
15 seconds) of the activity. 

[0125] Certain fields of a particular log entry may be 
left blank if not applicable to a particular service. For in- 
stance, for an FTP download. Where there is no outgo- 
ing traffic, the out-bytes field is left blank. Furthermore, 
additional fields may be added based on the type of 
service being logged. For instance, for an HTTP activity, 
the URL that is accessed is also logged in the log entry. 
The additional fields are preferably appended to the end 
of the standard log format. 

[01 26] A person skilled in the art should recognize that 
additions, deletions, and other types of modifications 
may be made to the log format without departing from 
the spirit and the scope of the invention as long as the 
log format common to all the policy enforcers and is 
aimed in creating compact logs. 
[0127] The log files created by the policy enforcers 
124, 126 are transferred to the policy server 122 based 
on archive options set by the policy server. In this regard, 
the network administrator specifies a threshold size for 
the logs created by the policy enforcers upon selection 
of the policy server archive option 752 of FIG. 9. When 
the log file exceeds the specified size, it is sent to the 
policy server 122. Preferably, the logs are transferred to 
the policy server 122 at least once a day even if the 
threshold size has not been exceeded. The logs may 
also be archived locally at the policy enforcer if so spec- 
ified by the network administrator. 
[0128] Once the policy server 122 receives the logs, 
it is stored in the archive database 31 8 preferably taking 
the form of an SQL database. The policy server reports 
module 316 queries this database to generate reports 
for each policy enforcer 124, 126. In addition, the logs 
may be exported in a format that may be interpreted by 
commercially available products such as WEBT- 
RENDS, manufactured by WebTrends Corporation of 
Portland, Oregon. 

[01 29] The reports created by the reports module 31 6 
include summary usage reports for the various resourc- 
es including policy enforcers, users, services, hosts, 
and VPNs. For instance, the reports may include VPN 
summary reports, bandwidth summary reports, packet 
filter reports, and the like, for each policy enforcer. 
[0130] The reports preferably show usage of each of 
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the resources over a period time. The start and the end 
date for the report may be specified by the user. The 
user may further drill down on the time dimension and 
on the resource dimension for viewing specific times 
and specific resources. For instance, in creating the 
packet filter reports, the user may indicate a start and 
end time, source IP address, source port, destination IP 
address, and destination port. All packets meeting these 
criteria are then fetched from the archive database 318 
and shown in a packet report. 

VIH. METHOD FOR SELECTIVE LDAP DATABASE 
SYNCHRONIZATION 

[01 31] According to one embodiment of the invention, 
the databases 130, 132, 134 in the unified policy man- 
agement system of FIG. 1 are LDAP databases storing 
policy management information including policies for 
firewall, VPNs, bandwidth, administration, user records, 
network records, services, and the like. As described 
above, the LDAP directory service model is based on 
entries where each entry is a collection of attributes. En- 
tries are arranged in a tree structure that follows a geo- 
graphical and organizational distribution. Entries are 
named according to their position in the hierarchy by a 
distinguished name (DN). 

[01 32] The policy server 1 22 preferably stores the pol- 
icy management information for all the policy enforcers 
in the policy server database 130. This information is 
organized in the databases 1 30 as one or more DNs 
with corresponding attributes. Appropriate portions of 
the policy server database are then copied to the policy 
enforcer databases 132, 134. 

[0133] FIG. 23 is a block diagram of an LDAP tree 
structure including an LDAP root 265 and a plurality of 
branches 264, 266, 268, 270. According to one exam- 
ple, the policy server 122 maintains in the policy server 
database 130 branches 264 and 266 with policy man- 
agement information for all the policy enforcers 124, 
126. Each of the policy enforcers 124, 126 also maintain 
portions of the branches 264 and/or 266 in their respec- 
tive policy enforcer databases 132, 134 as sub-trees of 
the policy server database 130. The portions of the 
branches maintained by each policy enforcer 124, 126 
preferably relates to the configuration information for 
that policy enforcer as well as some additional informa- 
tion about the other policy enforcers. This additional in- 
formation is used to communicate with the other policy 
enforcers. 

[0134] The policy server 122 may further maintain 
branch 268 storing information used only by the appli- 
cations running on the server and not shared with any 
of the policy enforcers 124, 126. Likewise, policy enforc- 
ers 124, 126 may maintain a portion of branch 268 con- 
taining information used only by the applications on 
each of the policy enforcers and not shared elsewhere. 
Typically, the data stored in branch 268 is dynamically 
generated and used by the applications running on the 



corresponding server or agent. 
[0135] Branch 270 is preferably only included in the 
LDAP tree for the policy server database 1 30 and stores 
logged policy management changes that may be prop- 
5 agated to the policy enforcers 124, 126. Such changes 
may include, for example, addition, deletion, or modifi- 
cations of a user on a device, VPN cloud, bandwidth pol- 
icy, or firewall policy made by the network administrator 
via the various graphical user interfaces described 
above. Such changes result in the updating of the policy 
database 130 where the corresponding DN of the LDAP 
tree is added, deleted, or modified. The policy server 
1 22 further creates a log of the changes and stores them 
in branch 270 for later distribution to the policy enforcers 
124, 126. 

[0136] FIG. 24 is a more detailed block diagram of 
branch 270 of the LDAP tree of FIG. 23. The LDAP root 
265 includes an ApplyLog 270a entry which in turn in- 
cludes a user log entry 270b and a device log entry 270c. 
The user log entries include specific administrator log 
entries identified by specific DNs 270d for reflecting the 
changes made by the particular administrators. The de- 
vice log entry 270c includes specific device log entries 
identified by specific DNs 270e reflecting the changes 
that are to be distributed to the particular policy enforces 
124, 126. Preferably, the changes made by the admin- 
istrators are propagated to the policy enforcers 1 24, 1 26 
upon actuation of an apply button such as the apply but- 
ton 417 illustrated in FIG. 6. 

[01 37] FIG. 25 is a flow diagram for logging and prop- 
agating LDAP changes to the policy enforcers according 
to one embodiment of the invention. In step 420, a par- 
ticular network administrator makes a policy setting 
change. According to one example, the administrator is 
administrator "adm" working in the domain "domainl," 
and the change is the addition of a new user on a device. 
[0138] In step 422, the change made the administra- 
tor is reflected in the policy server database 130. In this 
regard, branches 264 and 266 of the LDAP tree are 
modified accordingly to reflect the change in the policy 
setting. Additionally, in step 424, the policy server 122 
creates a log of the changes for the administrator for 
later processing and sending to the appropriate policy 
agent. In step 426, the policy server 122 updates the 
administrator's log DN 270d to reflect the change. 
[01 39] In the above example and as illustrated in FIG. 
24, if the log created is named "A_L1 the policy server 
1 22 updates the DN 270d for "adm" at "domainl " to cre- 
ate an attribute "apply" 270f that has the value "A_L1" 
270g. Other changes made by the administrator are re- 
flected in separate logs (e.g. "A_L2," "A_L3") and ap- 
pended to the existing value of the apply attribute in the 
administrator's log DN 270d. 

[0140] In step 428, the policy server 122 checks 
whether the changes made by the administrator are to 
be propagated to the appropriate policy enforcers 124, 
126. As discussed above, the changes are preferably 
propagated upon actuation of an apply button from the 
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administrator's graphical user interface. 
[0141] If the apply button has been actuated, the pol- 
icy server creates, in step 430. a log for each policy en- 
forcer to whom the change is to be transmitted. In this 
regard, the policy server 122 collects all the changes 5 
made by the administrator as reflected in the values 
270g, 270h of the apply attribute 270f of the administra- 
tor's log DN 270d. These changes are processed for 
each policy enforcer belonging to the administrator's do- 
main. Such processing preferably involves picking the 10 
relevant changes and suitably modifying the DNs for the 
policy enforcer's LDAP. Such suitable modifications may 
be necessary, for instance, due to the differences in the 
tree structures in the policy server database 1 30 and the 
policy enforcer databases 132, 134. For instance, a t5 
change in the administrator's log may contain a DN that 
specifies the domain name of the policy enforcer. In ap- 
plying this change to the policy enforcer, the domain 
name would not be specified in the DN since the policy 
enforcer's tree structure does not include a domain 20 
name. 

[0142] The changes suitably modified for each policy 
enforcer's LDAP are then stored in a device log. Each 
policy enforcer's log DN 270e is then modified to reflect 
the change to the transmitted to the particular policy en- 25 
forcer. In the above example and as illustrated in FIG. 
24, if the device log created is named "PE_L1 ," the pol- 
icy server 122 updates the DN 270e for the particular 
policy enforcer "PE1" at "domainl* to create an attribute 
"apply" 270i that has the value "PE_L1" 270j. 30 
[0143] In step 432, the apply attribute 270f for the ad- 
ministrator's log DN 270d is then deleted from the LDAP 
tree. In step 434, the changes collected for each policy 
enforcer, as reflected in the values 270j, 270k of the ap- 
ply attribute 270i of the policy enforcer's log DN 270e, 35 
are transmitted to the policy enforcer for updating its da- 
tabase 1 32, 1 34. The changes are sent to the policy en- 
forcers preferably over the HTTPS channel. 
[0144] In step 436, the policy server 122 checks 
whether the updates have been successful. In this re- *o 
gard, the policy server 122 waits to receive an acknowl- 
edgment from the policy enforcer that the updates have 
been successfully completed. Upon a positive response 
from the policy enforcer, the policy server 122 deletes 
the apply attribute 270e for the policy enforcer's log DN *5 
270e. Otherwise, if the update was not successful (e.g. 
because the policy enforcer was down), the apply log is 
re-sent the next time another apply function is invoked. 
Alternatively, the failed policy enforcer transmits a re- 
quest to the policy server 1 22 of the log of non-applied so 
changes when it rejoins the network (e.g. by rebooting). 

IX. STATE TRANSITION PROTOCOL FOR HIGH 
AVAILABILITY UNITS 

55 

[0145] According to one embodiment of the invention, 
the policy server 122, policy enforcers 124, 126, as well 
as other network devices may be configured for high 



availability by maintaining a backup unit in addition to a 
primary unit. 

[01 46] FIG. 26 is a schematic block diagram of a high 
availability system including a primary unit 902 and a 
backup unit 904. 

The two units 902, 904 communicate with each other by 
exchanging heartbeats over parallel ports 906a, 906b 
and a cable 908. Such parallel ports 906a, 906b and 
cable 908 are conventional components that are com- 
monly available in the art. 

[0147] The primary unit 902 and the backup unit 904 
are each similarly connected to other components 910, 
912, 914 via ports 920a, 920b, 922a, 922b, 924a, 924b, 
respectively. These components 910, 912, 914 may be 
hubs, switches, connectors, or the like. Because the pri- 
mary unit 902 and backup unit 904 provide similar serv- 
ices and functions and may be used interchangeably, 
each unit is preferably connected to the same compo- 
nents 910, 912, 914. 

[01 48] The parallel port cable 908 is preferably a con- 
ventional laplink cable designed to connect two parallel 
ports and allow communications between them. The pri- 
mary unit 902 and the backup unit 904 preferably com- 
municate with each other via TCP packets over the high- 
availability ports 906a, 906b. A point-to-point connec- 
tion preferably exists between the primary unit 902 and 
the backup unit 904 over the high-availability ports 906a, 
906b. 

[0149] The primary unit 902 is preferably responsible 
for checking the status of its network ports for problems 
or failures. For example, if the primary unit 902 detects 
that one of its network ports is inoperable, e.g. port 922a, 
the primary unit 902 then checks whether the corre- 
sponding port 922b in the backup unit 904 is operational. 
Upon determining that the corresponding port 922b in 
the backup unit 904 is operational, the primary unit 902 
sends a request to the backup unit 904 to take over the 
system functions as the active unit. The primary unit 902 
then relinquishes its role as the active unit and shuts 
itself down, allowing the backup unit 904 to take on the 
responsibilities of the primary unit 902. When the prima- 
ry unit 902 restarts operation, the backup unit 904 re- 
ceives a request from the primary unit 902 to relinquish 
its role as the active unit. 

[0150] When the primary unit 902 is active and does 
not detect any defects in its ports, it continuously listens 
on the high-availability port 906a to keep track of the 
status of the backup unit 904. The primary unit 902 con- 
tinues to listen on the high-availability port 906a for sig- 
nals coming from the backup unit 904. When the backup 
unit 904 is up and running, it connects to the primary 
unit 902. Once the connection is made, the backup unit 
904 begins sending heartbeats to the primary unit 902. 
The backup unit 904 continuously sends heartbeats to 
the primary unit 902 in predetermined intervals. Accord- 
ing to one embodiment of the invention, the backup unit 
904 sends a AKeep Alive® packet including a 
KEEP_ALIVE command to the primary unit 902 every 
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one second. 

[0151] The primary unit 902 responds to the "Keep 
Alive" packet by changing the command field of the 
packet to a KEEP_ALIVE_RESP command and re- 
transmitting the packet to the sender. If the backup unit 
904 does not receive a response back from the primary 
unit 902 for a predetermined period of time (e.g. one 
second) for one "Keep Alive" packet, the backup unit 
904 begins preparing to take over the active role. Pref- 
erably, the predetermined period should not be greater 
less than two consecutive "Keep Alive" packets. 
[0152] Upon taking the role of the active unit, the 
backup unit 904 attempts to reestablish a connection 
with the primary unit 902 at regular intervals to deter- 
mine whether the problem or failure in the primary unit 
has been cured. If the problem or failure has been cured, 
the backup unit 904 relinquishes its control to the prima- 
ry unit 902 after setting the IP addresses of all the net- 
work interface cards to the assigned value. 
[0153] In situations where the backup unit 904 takes 
over the active role from the primary unit 902, an alert/ 
alarm is sent to the network administrator indicating 
such a change. In addition, if the primary unit 902 does 
not receive heartbeats from the backup unit 904, an 
alert/alarm is sent to the administrator indicating that the 
backup unit has failed. 

[0154] A situation may arise when both the primary 
unit 902 and the backup unit 904 are fully functional, and 
the backup unit 904 desires to take over the active role. 
In this case, the backup unit 904 transmits a shut-down 
command to the primary unit 902 which then relinquish- 
es control. The backup unit 904 continues its role as the 
active unit until the primary unit 902 transmits a request 
to the backup unit 904 to relinquish its active role. 
[0155] According to one embodiment of the invention, 
the initial status determination protocol of each high 
availability unit as a primary, backup, or stand-alone unit 
relies on a self-discovery process. FIG. 27 is a flow di- 
agram of an exemplary status discovery process ac- 
cording to one embodiment of the invention. In step 930, 
a first high availability unit (unit X) that has not yet de- 
finitively discovered its status as a primary or a backup 
unit boots up, and in step 932 assumes the role of a 
backup unit. In step 934, unit X searches the network 
for a primary unit and inquires, in step 936, whether a 
primary unit has been detected. If the answer is YES, 
unit X tries to connect to the primary unit. If it is success- 
ful, unit X initializes as the backup unit in step 938. If, 
on the other hand, unit X does not detect the primary 
unit, unit X assumes the role of the primary unit in step 
940. 

[0156] In step 942, unit X searches the network for a 
backup unit. 

If the backup unit is detected, as inquired in step 944, 
unit X connects to the backup unit and initializes as the 
primary unit in step 946. If, on the other hand, unit X 
does not detect any other units in the network within a 
predetermined time, unit X initializes as a stand-alone 



unit in step 948. 

[0157] Once the primary and secondary units have 
been initialized, configuration changes of the primary 
unit are also transferred to the backup unit in order to 
5 keep the two units synchronized. The configuration in- 
formation is preferably stored in an LDAP database 
such as the central policy server database 1 30 or policy 
agent databases 124, 126. 

[01 58] FIG. 28 is a flow diagram of a process for main- 
10 taining configuration information synchronized in the pri- 
mary and backup units. In step 950, the primary unit 
boots up and in step 952, detects the backup unit. In 
step 954, the backup unit receives configuration change 
information from the primary unit if it is functional. Oth- 
15 erwise, the configuration changes are entered directly 
into the backup unit by the network administrator. If the 
configuration change is to be received from the primary 
unit, the primary unit notifies the backup unit when con- 
figuration changes occur in the primary unit. The chang- 
20 es are then transferred and applied to the backup unit. 
The backup unit in turn transmits the status of the trans- 
fer and the apply back to the primary unit. 
[0159] In step 956, the primary unit is checked to de- 
termine whether it is functional. If it is, the primary unit 
25 is likewise updated with the configuration change. Oth- 
erwise, if the primary unit is not functional, the backup 
unit takes on the active role and becomes the active unit 
in step 958. The primary unit may become non-function- 
al and thus, inactive, due failures in the CPU board, the 
30 network interface card, or power supply. 

[0160] In step 960, the backup unit tags the changes 
to transfer them to the primary once the primary be- 
comes functional. Once the primary unit becomes func- 
tional, the primary unit is updated with the tagged chang- 
es es maintained by the backup unit as is reflected in step 
962. 

[01 61] According to one embodiment of the invention, 
software updates on the primary and backup units are 
also synchronized so as to update the primary and back- 
40 up units serially in a single cycle without the need for 
multiple update cycles. Thus, the network administrator 
need not duplicate the efforts of updating the backup 
unit with the same information as the primary unit. 
[0162] FIG. 29 is an exemplary flow diagram of updat- 
es ing the primary and backup units when they are both 
functional. In step 970, an update, such as a software 
update not stored in the LDAP databases, is sent/trans- 
mitted to the primary unit from a management station 
accessible by the network administrator. The primary 
so unit then updates itself in step 972. In step 974, the pri- 
mary unit automatically sends/transmits the update in- 
formation to the backup unit. In step 976, the backup 
unit updates itself with the update information received 
from the primary unit. 
55 [01 63] FIG. 30 is an exemplary flow diagram of updat- 
ing the primary and backup units when the primary unit 
is not functional. In step 978, the primary unit becomes 
nonfunctional, and in step 980, the network administra- 
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tor sends/transmits an upgrade directly to the backup 
unit instead of the primary unit. In step 982, the backup 
unit updates itself with the information received from the 
management station and waits for the primary unit to 
become functional. Once the primary unit becomes 
functional, the update is automatically sent/transmitted 
to the primary unit for upgrading in step 986. The primary 
unit then updates itself in step 988. 
[0164] Although the present invention has been de- 
scribed in detail with reference to the preferred embod- 
iments thereof, those skilled in the art will appreciate that 
various substitutions and modifications can be made to 
the examples described herein while remaining within 
the spirit and scope of the invention as defined in the 
appended claims. 

[0165] For example, the unified policy management 
system of FIG. 1 should be viewed as illustrative rather 
than limiting. It should be apparent to those skilled in the 
art who are enlightened by the present invention that 
many alternative configurations are possible. For exam- 
ple, there may be additional networks with policy enforc- 
ers or no additional networks at all. Likewise, policy en- 
forcers may not necessarily access the policy server 
through the Internet, but may be connected via other 
means such as a WAN, MAN, etc. In short, the number 
and type of users and resources within and without the 
organization can vary greatly while staying within the 
scope of the invention. 



Claims 

1. A system for selective database synchronization 
comprising: 

a central database storing configuration infor- 
mation for a plurality of edge devices in an or- 
ganization, each edge device being associated 
with a network in the organization and config- 
ured to manage policies for the network; 
a subordinate database storing a portion of the 
configuration information associated with a par- 
ticular edge device; and a central policy server 
in communication with the central database 
and the subordinate database, the central pol- 
icy server including logic for: 

making a change to the portion of the con- 
figuration information associated with the 
particular edge device in the central data- 
base; 

creating a log of the changes; 

storing the log in the central database; and 

transferring the changes to the particular 

edge device for updating the subordinate 

database. 

2. The system of claim 1, wherein the log includes a 



user log for associating the change to a particular 
user making the change, the particular user being 
associated with the particular edge device. 

5 3. The system of claim 2, wherein the central policy 
server further includes logic for identifying the par- 
ticular edge device based on the particular user 
making the change. 

10 4. The system of claim 3, wherein the log includes a 
device log for storing the change for the particular 
edge device. 

5. The system of claim 1 , wherein the central policy 
15 server further includes logic for: 

receiving a status of the transfer from the particular 
edge device; and deleting the log from the central 
database if the status indicates a successful trans- 
fer. 

6. The system of claim 1 , wherein the central database 
and the subordinate database are Lightweight Di- 
rectory Access Protocol (LDAP) databases storing 
configuration information as an LDAP entry identi- 
fied by a distinguished name. 

7. The system of claim 1 , wherein the configuration in- 
formation is policy management information. 

8. A method for selective database synchronization 
comprising: 

storing in a central database configuration in- 
formation for a plurality of edge devices in an 
organization, each edge device being associ- 
ated with a network in the organization and con- 
figured to manage policies for the network; 
storing in a subordinate database a portion of 
the configuration information associated with a 
particular edge device; and making a change 
to the portion of the configuration information 
associated with the particular edge device in 
the central database; 
creating a log of the changes; 
storing the log in the central database; 
transferring the changes to the particular edge 
device; and updating the subordinate database 
based on the changes. 

9. The method of claim 8, wherein creating the log of 
the changes further comprises creating a user log 
for associating the change to a particular user mak- 
ing the change, the particular user being associated 
with the particular edge device. 

1 0. The method of claim 9 further comprising identifying 
the particular edge device based on the particular 
user making the change. 
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11. The method of claim 10, wherein the creating the 
log of changes further comprises creating a device 
log for storing the change for the particular edge de- 
vice. 

5 

12. The method of claim 8 further comprising: 
receiving a status of the transfer from the particular 
edge device; and deleting the log from the central 
database if the status indicates a successful trans- 
fer. 10 

13. The method of claim 8 t wherein the central data- 
base and the subordinate database are Lightweight 
Directory Access Protocol (LDAP) databases stor- 
ing configuration information as an LDAP entry 15 
identified by a distinguished name. 

14. The method of claim 8, wherein the configuration 
information is policy management information. 
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